Consumers increasingly have some sort of IP network connection in their home, normally for access to the public Internet. In addition to Internet access, voice over IP (VOIP), and other consumer data needs, audio and video providers can use these connections to deliver content to customers, thus providing consumers with a single source for data consumption.
Providing reliable audio/video delivery to a wide body of consumers over IP networks presents the content provider with several challenges. For one, not all consumers will be able to receive data at the same rate of delivery. In particular, due to network topology and data demands from consumers at other points in the network, certain consumers will be able to receive data at much higher bitrates than others. Ideally, a content provider should give each consumer an acceptable experience. In practice, however, a provider can deliver content to consumers with low-volume connections by changing the characteristics of the audio/video data so as to allow delivery of the same content with less data, though with reduced playback quality. Attempting to deliver content with a higher volume of data than the consumer can effectively receive will result in data loss which will cause discontinuity and corruption in the final audio/video playback.
Another challenge is that consumers may wish to use a wide variety of devices to play back the audio/video data. Some consumers will wish to watch videos on their televisions; others will watch videos on their home computers, laptops, or tablet computers; others will wish to watch videos on their cell phones. Each device may have a different capacity for playing back content, and may further restrict the volume of data that can be effectively delivered to the consumer.
A further challenge is that a consumer's capacity to receive data may change from time to time. This may occur due to factors outside the consumer's control (data demands from other consumers; network failures and interference; etc.) as well as conditions controlled by the consumer (moving a device with wireless access closer to or further away an in-house access point; activating other devices in the home which may compete for data consumption; etc).
Yet another challenge is that many consumers will wish to receive “real time” content, such as ongoing sporting events or concerts, or “broadcast” content in the form of network broadcast channels which transmit programs continually, one after another, at scheduled times. Consumers will wish to receive this content “now,” at the same time that other consumers (who may not have the same provider) will be seeing the same content.
In addition, some decisions about how to provide content to consumers are best made at network locations closer to the consumers themselves. For instance, if a provider has 10,000 consumers, and 20 of those consumers reside in the same apartment building and share a single narrow network connection into the building, it would not make sense to transmit all possible live content to that apartment building, since this would overload the building's network connection. It would make more sense to transmit only the content currently requested by the building's consumers, and then relay that content to the individual consumers who have requested it. The job of collecting and relaying content would be best served by a server dedicated specifically to that apartment building, which would need to interact with some master server or servers in order to collect the necessary content.
A consumer will have the best possible playback experience, regardless of network conditions, if the consumer possesses a full local copy of the content to be played back. However, delivering a full copy of the content to a consumer is undesirable for two primary reasons. First, the client may not possess sufficient data storage capacity to store the entire body of the media content. Second, the time required to deliver the content will produce a substantial delay (possibly as long as hours) between the time the consumer indicates a desire to receive the content and the time that the consumer is actually able to begin playing back the content. There may also be copyright issues involved with full-copy distribution.
There are several tools available for solving all of the above challenges, but each tool either addresses only part of the overall solution, or introduces its own challenges. Encoding and compression technologies can produce different versions of the same contents with different bitrates. Content produced at lower bitrates will not have the same quality as content of higher bitrates, but will be more easily provided to consumers with low-volume data connections. Many web sites allow consumers to choose which bitrate they prefer to receive, but this requires a higher level of interaction than would be expected from a “traditional” television experience, where consumers would not many only need to choose which channel they wish to view, and would not need to estimate and regulate their own network usage. In addition, choosing a single bitrate leaves the consumer vulnerable to periodic fluctuations in network availability, which may periodically reduce a consumer's capacity to receive data, and so a high-bitrate stream which the consumer had been receiving without difficulty is now too large for the consumer to receive on a timely basis. And, of course, the provider cannot simply transmit the same content at several bitrates to the consumer, since this increases the consumer's data load rather than reducing it.
A technology known as HTTP adaptive streaming requires the server to encode small segments of a program at different bitrates. The client will request these segments in order and play them back, and can switch between receiving higher-bitrate segments and lower-bitrate segments as necessary based on current network conditions. This solution, however, requires data to be sent separately to each consumer, and does not allow for more efficient use of network resources by technologies such as multicast. In addition, this solution, as well as any similar adaptive solution requiring intelligence or decisions from the client device, requires a specially-constructed client device or client software application, and cannot be implemented using off-the-shelf IP television set-top boxes which expect to passively receive audio/video IP data in a single continuous stream.
IP multicasting reduces the load on data sources by allowing sources to provide their data to intermediate nodes, rather than to individual clients. For instance, a server might transmit its data ten times, once to each of ten intermediate nodes. These nodes then relay this data to ten clients each. In this way, the server has provided data to one hundred clients, even though it only sent the original data ten times. This is a common IP technology, but currently, many wi-fi access points do not handle multicast traffic well, and consumers using wi-fi access points would not be able to reliably receive content delivered via multicast. These consumers would require unicast transmissions delivered directly to the addresses of the devices connected via wi-fi.
Forward error correction (FEC) allows a data provider to include additional data within a signal that will allow a client to recalculate missing data, if some portions of the data are lost during transmission. The provider must determine how much data loss the client will be able to recalculate; it is possible to allow the client to recalculate a higher percentage of lost data by including a higher amount of additional FEC data in the data stream. Adding more FEC data, however, increases the total size of the data stream, and so the provider must balance the need for smaller data streams against the need to allow clients to recalculate lost data. When the rate of data loss has exceeded the ability of the FEC algorithm to recalculate the lost data (based on the amount of FEC provided) then data loss is inevitable.
Allowing the client (or some intermediate entity) to buffer data before delivering it or playing it back can alleviate some of the problems caused by a temporary loss of data capacity. If a client stores ten seconds worth of data before starting to play it back, that client might, in theory, be able to tolerate a loss of connection to the server for up to ten seconds without any interruption in playback; it would simply use its buffer of stored data during those ten seconds of disconnection. This, however, is another case where the solution does not provide for a traditional television-style viewing experience, where consumers are accustomed to being able to watch video content as soon as they turn on their television and select a channel. Also, this solution is only effective so long as the client is able to keep some amount of data in its buffer. If the client exhausts its buffer due to frequent or prolonged loss of signal from the source, the client will no longer have any data to provide for playback, and must halt until delivery of data can be restored.
Connecting to the clients using the TCP protocol allows for guaranteed, lossless delivery of data to clients. However, this protocol does not guarantee timely delivery of data, and delays in delivery may be experienced due to network conditions. This may interrupt smooth playback on the client end, and may also delay data so that it is no longer being delivered close to real time, in situations where a “live” real-time stream is being provided.
In summary, consistent delivery of media data over large, generally unmanaged networks continues to be a common problem. There is an outstanding need for a system and method to deliver the best quality data while simultaneously satisfying all clients on the network.